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(54) Web application development system 

(57) It is demanded to add a new service to the Web 
quickly and to develop a Web application system in a 
short period of time to extend a service, it is thus nec- 
essary to alleviate the burden on developers or pro- 
grammers to speed up development, and to cope with 
complicated systems or to make systems extensible. 
Thus, the system has to be designed to clearly associate 
components with one another and separate their re- 
spective roles. In the development of a Web application 
system, each of the components of the servlet, JSP, and 



Bean is defined in a one-to-one relationship correspond- 
ing to each screen image, thereby making the relation- 
ship among each of the components clear. A component 
table generating unit is provided for generating the def- 
inition of each component as a component table from 
screen design. Also provided is an automatic code gen- 
erating unit for automatically generating the code of 
servlet, JSP, and Bean using the component table and 
the information of the design document. This facilitates 
the development and alleviates the burden on develop- 
ers or programmers. 
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Descrlpti n 

BACKGROUND OF THE INVENTION 

1. FIELD OF THE INVENTION 

[0001] The present invention relates to a method for 
developing a Web application and to a development 
support system. More particularly, it relates to a support 
technology for designing and developing a servlet, JSP, 
and JavaBearts component (Bean) in a Web application 
system which employs the server-side Java technology. 

2. DETAILED DESCRIPTION OF THE PRIOR ARTS 

[0002] Recently, in a Web application system on the 
Inter- and Intranet, such a system has come into wide- 
spread use that makes use of the server-side Java tech- 
n logy. Conventional Web systems typically employ 
CGI (Common Gateway Interface) programs. However, 
servtets are substituting for the CGI to become main- 
stream in the development of systems. The servlet pro- 
vides the functionality similar to the CGI and is a server- 
side program for executing on a server for a request sent 
from a client (Web browser) and then sending back the 
resulting data to the client 

[0003] It is the most basic that the servlet is used as 
follows. The servlet is activated according to a request 
sent from a Web browser to gain access to a database, 
receive, and then process the resulting data. In addition, 
the servlet performs branched processing or calls other 
servlets according to the contents of the request to send 
back the resulting data to the Web browser. In some cas- 
es, JSP*s (JavaServer Pages) are employed instead of 
the servlet The JSP technology is a major extension to 
write Java codes into HTML file and can be combined 
with the servlet to be used together. 
[0004] In a conventional system configured by em- 
ploying the servlet, JSP, and Bean, the Bean accesses 
databases as well as performs business transactions, 
also acts to hold the resulting data. Designing and de- 
veloping the Bean used to require knowledge and ex- 
perience on Java more than the development of the JS P. 
In addition, in the conventional development, each com- 
ponent was shared on the server side to develop sepa- 
rately a servlet, JSP and Bean that is utilized by them. 
Thus, as can be seen in the waterfall development, it 
was necessary to clearly define the target of develop- 
ment in advance. 

[0005] In recent system developments, the develop- 
ment cycle time has been increasingly made shorter. In 
particular, to make a business system or a business 
service public on the Web, customers require strongly 
to make the development cycle time shorter Thus, in a 
Web application system, it is required not only to peri- 
odically update the design or information of Web pages 
but also to make a new service public as soon as pos- 
sible on the system or quickly extend the service, that 



is.tocomplet development in a sh rterp ri d of time. 
To cope with these customer needs as well as a shorter 
developm nt cycle tim for Web application systems, it 
is necessary to alleviate the burden on dev topers or 
5 programmers and provide a significant speedup in the 
development 

[0006] Furthermore, the conventional development 
method allowed the servlet and JSP to perform process- 
ing according to a request and then describe a program 

io for creating a screen in accordance with the resulting 
data. Accordingly, this caused the system to become 
larger, and made it necessary for individual developer 
to have wider knowledge on Java as the system and 
programming became more complicated, and collect 

' 5 Java programs for the development. The developers or 
programmers were further burdened with understand- 
ing the processing performed by the servlet or JSP to 
be developed, coding, debugging, and maintenance 
thereof. 

20 [0007] When each servlet and Bean employed by the 
servlet were independently developed, they could not 
be combined together to check the overall operation un- 
til developers provided their classes. On the other hand, 
when the servlet and Bean are independently devel- 

25 oped, it is impossible to achieve commonality since the 
developers develop a servlet, JSP, and Bean independ- 
ently of one another. This made the development de- 
pendent on the skill of each developer and the mainte- 
nance difficult to be carried out. 

30 

SUMMARY OF THE INVENTION 

[0008] The present invention was developed to solve 
the aforementioned problems. That is, an object of the 

35 present invention is to alleviate the burden on develop- 
ers or programmers who design and develop a servlet, 
JSP, Bean in a Web application system that employs the 
server-side Java technology, thereby providing a spee- 
dup in the design and development 

40 [0009] To achieve the aforementioned object, a first 
aspect of the present invention provides a Web applica- 
tion development method for developing, on the Inter- 
and Intranet, a Web application system having server- 
side Java technologies such as a servlet, JSP, and Java- 

45 Beans component (Bean). The method is characterized / 
in that in accordance with a GUI specification provided 
by a design specification for said Web application sys- 
tem, a source filename of each component of the serv- 
let, JSP, and Bean is defined corresponding to each 

50 screen image to develop the servlet, JSP, and Bean. 
[0010] A second aspect of the present invention is a 
Web application development method for developing, 
on the Inter- and Intranet, a Web application system 
having server-side Java technologies such as a servlet, 

55 JSP, and JavaBeans component (Bean). The method is 
characterized in that in accordance with a GUI specifi- 
cation provided by a design specification for said Web 
application system, a source filename of each compo- 
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n nt of the servlet; JSP, and Bean is defined in a one- 
to-one relationship corresponding t each screen image 
t develop th servlet, JSP, and Bean. 
[0011] A third aspect of the pres nt invention is char- 
acterized in that, in th first or second aspect, a source 
code of ach component is automatically generated us- 
ing the r lationship between said sere n and a source 
filename of each component of said servlet, JSP, and 
Bean, and information of said design specification. 
[001 2] A fourth aspect of the present invention is char- 
acterized in that, in the first or second aspect, said Bean 
component is provio^ with alkp 
necessary for displaying aaKTME page, and serves to 
carry out mapping information of an HTML page and in- 
formation to be retrieved from a database. 
[0013] A fifth aspect of the present invention is char- 
acterized in that, in the third aspect, upon generation of 
the source code of each component of said servlet, JSP, 
and Bean, a template list is displayed for each compo- 
nent to be generated, a template selected from the tem- 
plate Bst is employed as a model, and a code is written 
to the model in accordance with said design specifica- 
tion to automatically generate a source code. 
[001 4] A sixth aspect of the present invention is a Web 
application development method for developing, on the 
Inter- and Intranet, a Web application system having 
server-side Java technologies such as a servlet, JSP, 
and JavaBeans component (Bean). The method is char- 
acterized by comprising the step of reading a GUI spec- 
ification provided by a design specification to generate 
each component name of a servlet, JSP, and/or Bean 
corresponding to a screen name for each screen. The 
method also comprises the step of selecting a template 
from a template list with respect to each component of 
a generated name, the template being a model of a 
source file of the component The method further com- 
prises the step of generating automatically a source 
code of the component by writing the code to said tem- 
plate in accordance with a design specification of the 
component 

[0015] A seventh aspect of the present invention is 
characterized in that, in the sixth aspect, said template 
list includes a superclass template, and the step of gen- 
erating automatically said source code is to inherit said 
superclass to create said source code. 
[0016] An eighth aspect of the present invention is 
characterized in that, in the sixth aspect, said step of 
generating a name of each component is to generate a 
name of each component of a servlet, JSP, and/or Bean 
in a one-to-one relationship with a screen name for said 
each screen. 

[0017] A ninth aspect of the present invention is char- 
acterized in that, in any of the first - eighth aspects, in a 
Web application system to be developed, the servlet 
serves to receive a request from a Web browser; the 
Bean serves to perform processing in accordance with 
the request of the servlet to hold resulting data; and the 
JSP serves to retrieve the resulting data of the Bean to 



gen rate an HTML displayed h the Web brows r. Thus, - 
each role of the servlet, JSP, and Bean is separated from 
each other. 

[001 8] A tenth aspect of the present invention is a pro- 

5 gram provided by a method for developing a Web appli- 
cation according to any one of the foregoing aspects. 
[0019] An feventh aspect of th present invention is 
a storage medium for storing a program provided by a 
method for developing a Web application according to 

10 any one of the first to the ninth aspects. 

[0020] A twelfth aspect of the present invention is a 
Web application development system for developing, on 
the Inter- and Intranet, a Web application system having 
server-side Java technologies such as a servlet, JSP, 

15 and JavaBeans component (Bean). The system is char- 
acterized by comprising means for developing the serv- 
let, JSP, and Bean by defining a source filename of each 
component of the servlet, JSP, and Bean corresponding 
to each screen image, in accordance with a GUI speci- 

20 fication provided by a design specification for said Web 
application system. 

[0021] A thirteenth aspect of the present invention is 
a Web application development system for developing, 
on the Inter- and Intranet, a Web application system 

25 having server-side Java technologies such as a servlet, 
JSP, and JavaBeans component (Bean) . The system is 
characterized by comprising means for developing the 
servlet, JSP, and Bean by defining a source filename of 
each component of the servlet, JSP, and Bean in a one- 

30 to-one relationship corresponding to each screen im- 
age, in accordance with a GUI specification provided by 
a design specification for said Web application system. 
[0022] A fourteenth aspect of the present invention is 
characterized in that, in the twelfth or thirteenth aspect, 

35 by further comprising means for automatically generat- 
ing a source code of each component, using the rela- 
tionship between said screen and a source filename of 
each component of said servlet, JSP, and Bean, and in- 
formation of said design specification. 

40 [0023] A fifteenth aspect of the present invention is 
characterized in that, in the twelfth or thirteenth aspect, 
said Bean component is provided with all pieces of in- 
formation necessary for displaying an HTML page, and 
serves to carry out mapping information of an HTML 

45 page and information to be retrieved from a database. 
[0024] A sixteenth aspect of the present invention is 
characterized in that, in the fourteenth aspect, by further 
comprising, upon generation of the source code of each 
component of said servlet, JSP, and Bean, means for 

so displaying a template list for each component to be gen- 
erated, for employing a template selected from the tem- 
plate list as a model, and for writing a code to the model 
in accordance with said design specif cation to automat- 
ically generate a source code. 

55 [0025] A seventeenth aspect of the present invention 
is a Web application development system for develop- 
ing, on the Inter- and Intranet, a Web application system 
having server-side Java technologies such as a servlet, 
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JSP; and Java Beans compon nt (Bean) : The system is 
characterized by comprising means for reading a GUI 
specification provided by a design specification t gen- 
erate each component name of a s rvlet, JSP, and/or 
Bean corresponding to a screen name for each screen. 
The system is also characterized by comprising means 
for selecting a template from a template list with respect 
to each component of a generated name, the template 
being a model of a source file of the component The 
system is also characterized by comprising means for 
generating automatically a source code of the compo- 
nent by writing the code to said template in accordance 
with a design specification of the component 
[0026] An eighteenth aspect of the present invention 
is characterized in that, in the seventeenth aspect, said 
template list includes a superclass template, and the 
m ans for generating automatically said source code 
are to inherit said superclass to create said source code. 
[0027] A nineteenth aspect of the present invention is 
characterized in that, in the seventeenth aspect, said 
means for generating a name of each component is to 
generate a name of each component of a servtet, JSP, 
and/or Bean in a one-to-one relationship with a screen 
name for said each screen. 

[0028] A twentieth aspect of the present invention is 
characterized in that, in any one of the twelfth to nine- 
teenth aspects, in a Web application system to be de- 
v loped, the servlet serves to receive a request from a 
Web browser; the Bean serves to perform processing in 
accordance with the request of the servlet to hold result- 
ing data; and the JSP serves to retrieve the resulting 
data of the Bean to generate an HTML displayed on the 
Web browser. Thus, each role of the servlet, JSP, and 
Bean is separated from each other. 
[0029] That is the present invention is characterized 
by comprising a component table for defining in list form 
th source filename of each component of the servlet, 
JSP, and Bean in a one-to-one relationship correspond- 
ing to each screen image of the GUI specification pro- 
vided by a design document The invention is also char- 
acterized by comprising an automatic code generating 
unit for automatically extracting and generating, as a 
source code, the name, variable, and method definition 
of each component of the servlet, JSP, and Bean, and 
the call relationship among the components by making 
use of the information of the component table and the 
design document. Template data that includes a code 
or template of each component, used upon generation 
of source codes in the automatic code generating unit, 
is stored in a predetermined external storage unit. Also 
stored therein are source codes or servlet superclasses 
and source codes of each component generated. 
[0030] As described above, in the development of a 
Web application system, the source filename of each 
component of the servlet, JSP, and Bean is defined in a 
one-to-one relationship corresponding to each screen 
image. This makes it possible to clarify the relationship 
between each of the components. Furthermore, each 



screen can b dev toped independentiyby standardize 

ing th processing of the servtet, JSP, and Bean. 
[0031] Furthermor ,th relationship between each of 
the components is made clear for each screen and their 

5 respective roles are designed to be separate from each 
other, thereby making it possible to cope readily with a 
complicated system or xtend easily the function of the 
system. Use of the server-side Java technology would 
make it possible to separate the rotes of the servlet, JSP, 

io and Bean from each other in a manner such that the 
servlet serves to receive a request from a Web browser; 
the Bean serves to perform processing in accordance 
with the request of the servtet to hold resulting data; and 
the JSP serves to retrieve the resulting data of the Bean 

is to generate an HTML displayed on the Web browser. In 
particular, the Invention is characterized in that the Bean 
is designed to have all pieces of information necessary 
for displaying an HTML page using the resulting classes 
provided by the analysis and design of business rules 

20 or classes for accessing a database. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0032] Fig. 1 is a view depicting an example of a com- 
25 ponent table representative of the relationship among 
the screen, the servtet, JSP, and Bean of a Web appli- 
cation system to be developed. 
[0033] Rg.2 is a view depicting an example of the con- 
figuration of a system according to an embodiment. 
30 [0034] Fig.3 is a view depicting an example of the 
overall configuration of a Web application system which 
employs the servtet, JSP, and Bean. 
[0035] Fig.4 is a view depicting an example of a flow- 
chart for generating a component table. 
35 [0036] Fig.5 is a view depicting an example of a flow- 
chart for automatically generating a source code. 
[0037] Ffg.6 is a view depleting an example of a flow- 
chart for automatically generating a servlet source code. 
[0038] Rg.7 is an explanatory view depicting a flow 
for generating a servlet source code. 
[0039] Fig.8 is a view depicting an example of a serv- 
let superclass source code. 

[0040] Fig. 9 is a view depicting an example of a flow- 
chart for automatically generating a JSP source code. 
45 [0041 ] Fig. 1 0 is an explanatory view depicting a flow 
for generating a JSP source code. 
[0042] Fig. 1 1 is a view depicting an example of a flow- 
chart for automatically generating a Bean source code. 
[0043] Fig. 1 2 is an explanatory view depicting a flow 
so for generating a Bean source code. 

[0044] Fig.1 3 is a view depicting the relationship be- 
tween screen information and Bean. 
[0045] Fig. 14 is a view depicting the overall configu- 
ration of a Web application system which employs the 
55 servlet, JSP, and Bean, according to a second embod- 
iment. 

[0046] Fig. 1 5 depicts the relationship between the re- 
cipient component and the response component, which 
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ar employed in a Web-appticatiorr system according t 

the second embodim nt. 

[0047] Fig. 16 is a view depicting a (first) xampl of 
defining a one-to-one relationship between the recipient 
and res pons components. 5 
[0048] Fig. 1 7 is a view depicting a (second) example 
of defining a one-to-one relationship between th recip- 
ient and response components. 
[0049] Fig. 18 is a view depicting a (first) example of 
a component definition table of components. 10 
[0050] Fig. 1 9 is a view depicting a (second) example 
of a component definition table of components. 
[0051] Fig.20 is a view depicting an example of the 
configuration of a system for designing and developing 
a Web application system. 15 
[0052] Rg.21 is a view depicting an example of a de- 
velopment procedure for designing and developing a 
Web application system. 

[0053] Flg.22 is a flowchart depicting a flow for gen- 
erating a component definition table. , 20 
[0054] Fig.23 is a flowchart depicting a flow for auto- 
matically generating a source code. 
[0055] Rg.24 is a flowchart depicting a flow for auto- 
matically generating a servlet source code. 
[0056] Hg.25 is a view depicting a (first) example of 25 
generating a servlet source code. 
[0057] Fig.26 is a view depicting a (second) example 
of generating a servlet source code. 
[Q058] Fig.27 is a view depicting an example of a serv- 
let superclass code. 30 
[0059] Fig.28 is a view depicting a (first) image of se- 
lecting a template. 

[0060] Fig.29 is a view depicting a (second) image of 
selecting a template. 

[0061] Fig.30 is a flowchart depicting a flow for auto- 35 
maticalry generating a Bean source code. 
[0062] Fig.31 is a view depicting an example of gen- 
erating a Bean source code. 

[0063] Fig.32 is a view depicting the relationship be- 
tween screen information and Bean. 40 
[0064] Fig.33 is a flowchart depicting a flow for auto- 
matically generating a JSP source code. 
[0065] Fig.34 is a view depicting an example of gen- 
erating a JSP source code. 

[0066] Fig.35 is a view depicting an image of editing 
a source code. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

50 

[0067] Now, embodiments of the present invention 
are explained specifically with reference to the accom- 
panying drawings. 

[0068] A first embodiment according to the present in- 
vention is explained below. Here, such an example is 55 
explained in which a Web application system employing 
th servlet, JSP, and Bean, described later with refer- 
ence to Fig. 3, is designed and developed. In particular, 



th pres ntinv ntion is charact rized in thatthe^ource— 
file name of each of the components of the servlet, JSP, 
and Bean is defined as a compon nt table by b ing as- 
sociated in a one-to-one relationship with each of the 
screens of the GU I specification in the design docum nt. 
Using the information in the component table and the 
design document, th name and variable of ach com- 
ponent of the sen/let, JSP, and Bean, the definition of 
methods, and each call relationship among the compo- 
nents are automatically extracted to automatically gen- 
erate source codes. 

[0069] Fig. 1 is a view depicting an example of a com- 
ponent table representative of the relationship among 
the screen, the servlet, JSP, and Bean of the Web ap- 
plication system to be designed and developed in this 
embodiment The component table 101 comprises the 
screen name 1 02, the JSP name 1 03, the servlet filena- 
me 1 04, and the Bean filename 1 05, where each filena- 
me is defined to be associated in a one-to-one relation- 
ship with each screen image. It will be understood that 
the JSP name 103 has an extension sign of "jsp", and 
the servlet filename 1 04 and Bean filename have an ex- 
tension sign of "Java". For example, for the screen name 
of the "New Order Screen", the JSP name 1 03 is 'Order. 
Jsp", while the servlet filename 104 is a JSP name 103 
added by "Servlet", or the "OrderServietjava". Similarly, 
the Bean filename 105 is a JSP name 103 added by 
"Bean", or the "OrderBean.java". An "Error display 
screen" 1 06 is not associated in a one-to-one relation- 
ship with the servlet and Bean but is called by some 
sen/lets, and thus only the "Error jsp" is defined accord- 
ing to the JSP name 1 03. 

[0070] Referring to Fig.1 , reference numeral 1 07 des- 
ignates an external storage unit for storing a variety 
pieces of information. The external storage unit 107 
stores information necessary to generate the source 
codes 110, 113, 116 of each of the components of the 
servlet, JSP, and Bean, which are defined in the com- 
ponent table 101. Reference numerals 108 and 109 
designate information necessary to generate the JSP 
source code 110 and comprising a design document 1 08 
for describing screen images, form data specifications, 
event specifications, and screen transition diagram; and 
template data 109. Reference numerals 111 and 112 
designate information necessary to generate the servlet 
source code 113 and comprising a design document 111 
for describing package definition tables, screen transi- 
tion diagrams, error tables, form data specifications, and 
Bean public method tables; template data 112, and serv- 
let superclass source code data. Reference numerals 
114 and 115 designate information necessary to gener- 
ate the Bean source code 116 and comprising a design 
document 114 for describing package definition tables, 
class diagrams, sequence diagrams, form data specifi- 
cations, and Bean public method tables; and template 
data 115. 

[0071 ] Fig .2 is a view depicting an example of the con- 
figuration of a system for designing and developing a 
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Web applicati n system: Referring to Fig:2; ref r nee 
numeral 201 designates a terminal for inputting com- 
mands and op ration with a mouse; reference numeral 
202 designates a central processing unit for storing 
functionality and data for implementing th present in- 
vention; and reference numeral 203 designates an ex- 
ternal storage unit for storing various pieces of informa- 
tion. A design document 204 stored in the external stor- 
age unit 203 includes GUI specifications to be obtained 
from the requirements and business specifications pro- 
vided by customers for the development of a Web ap- 
plication system, and HTML files representative of 
screen design and each screen image. Referring back 
to Fig.1, the design documents, template data, and 
source codes generated, designated by reference nu- 
merals 1 08 to 11 6, are stored in the external storage unit 
203. In the external storage unit 203, also stored is the 
servtet superclass source code data 212. 
[0072] The functionality stored in the central process- 
ing unit 202 comprises a component table generating 
unit 205 for reading screen information from the GUI 
specification stored in the design document 204 to gen- 
erate a component table 208 representative of the rela- 
tionship among the screen, servlet, JSP, and Bean. The 
functionality also comprises an automatic code gener- 
ating unit 207 for automatically generating each source 
code of the servlet, JSP, and Bean by making use of a 
component table 206, the information of the design doc- 
ument 204 such as the GUI specification and a system 
design document, and template data 208. The template 
data 208 includes source codes which are used as a 
template for each component upon generation of source 
codes and which form superclasses in the servlet Each 
source code generated by the automatic code generat- 
ing unit 207 Is stored In servlet source code data 209, 
JSP source code data 210, and Bean source code data 
211. 

[0073] Fig.3 is a view depicting an example of the 
overall configuration of a Web application system which 
employs the servlet, JSP, and Bean, generated by the 
automatic code generating unit 207 of the system ac- 
cording to this embodiment This Web application sys- 
tem is used by a Web browser 302 on a client 301 . A 
HTML page 303 is displayed on the Web browser 302. 
A request from the Web browser 302 is sent to a server 

304 via HTTP. The server 304 comprises a HTTP server 

305 and an application server 306 which in turn includes 
a runtime environment of the servlet and JSP. 
[0074] The servlet, JSP, and Bean, generated by the 
automatic code generating unit 207, are each executa- 
bty arranged on the application server 306 of the server 
304. Sending a request to the server 304 will cause a 
corresponding servlet 307 to execute according to the 
request. The servlet 307 issues a request to a corre- 
sponding Bean 308 to perform processing. Then, the 
Bean 308 uses a DB access object 31 0 to access a da- 
tabase 31 1 and then perform processing related to busi- 
ness and data processing, then holding the resulting da- 



ta. The DB access- bject31 0 is a class created through - 

the analysis and design of business rules, or an existing 
reusable class. Subsequently, th servlet 307 passes 
the Bean 308 to a JSP 309 to call the JSP 309. By re- 

s trievingth resulting data held in th Bean 308, th JSP 
309 generates and then sends an HTML page back to 
the client 301 . The HTML page sent back as such is dis- 
played on the Web browser 302. Here, the servlet 307, 
JSP 309, and Bean 308 are defined in a one-to-one re- 

10 lationship with the HTML page 303 to be displayed on 
the Web browser 302. 

[0075] The servtet 307 receives a request from the 
Web browser 302, issues the request to the Bean 308, 
and calls the JSP 309, thus serving to connect between 

15 and control each of them. The JSP 309 serves to display 
the output of an HTML page, while the Bean 308 serves 
for business transactions. Without using the Bean 308 
and the JSP 309, it is also possible to process a request 
from the Web browser 302 only with the servlet 307. 

20 However, using the Bean 308 and the JSP 309 makes 
It possible to dearly separate their respective roles, 
thereby allowing each of their functions to be grasped 
in a simple manner. 

[0076] Now, referring to Rg.4, a process flow is ex- 

25 plained for generating the component table 101 in the 
component table generating unit 205. First, all pieces of 
screen information are read from the GUI specification 
stored in the design document 204 (step 401). The 
screen name and screen code name are retrieved from 

30 the screen information (step 402). For example, the 
screen code name can be retrieved from the filename 
of HTML files created as each screen image or may be 
defined as the screen information. Alternatively, the 
screen code name can be inputted for each screen from 

35 the terminal 201 . Here, an explanation is given assum- 
ing that the screen name retrieved is "New order screen" 
and the screen code name is "Order". Now, the retrieved 
screen code name is supplied with an extension sign of 
"jsp" to form a JSP name (step 403). The screen code 

40 name is added by "Servlet" and supplied with an exten- 
sion sign of ".Java" to form a servlet filename (step 404). 
The screen code name is added by "Bean" and supplied 
with an extension sign of " Java" to form a Bean filename 
(step 405). Here, the filenames are defined as "Order. 

45 jsp", ■OrderServlet java", and "orderBean Java" , respec- 
tively. The screen name and the filenames or the defined 
JSP name, servlet filename, and Bean filename are set 
to corresponding positions in the component table 101 
(step 406). It is determined whether processing has 

50 been performed on all pieces of screen information re- 
trieved in step 401 (step 407). If not, processing is re- 
peated from step 402 to 406 until all pieces of informa- 
tion are processed. When all pieces of screen informa- 
tion have been processed, the component table 101 is 

55 finally generated and then control exits (step 408). The 
component table 101 generated in this step may be 
stored in the design document 204. 
[0077] Now, referring to Fig. 5, a process flow is ex- 
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~ plained for autcxnatk^ty generating e^^ souix^-code 
of the servtet, JSP, and Bean in the automatic code gen- 
erating unit 207. First, the compon nt table 1 01 gener- 
ated in the component table generating unit 205 is read 
(step 501). The screen name 102 is retrieved from the 
component table 101 (step 502). An explanation is given 
here assuming that the screen name retrieved is "New 
order screen". It is checked whether all of the JSP name 
1 03, servlet filename 1 04, and Bean filename 1 05 have 
been set corresponding to the screen name retrieved 
(step 503). Take the "Error display screen* 106 in Fig.1 
as an example. Here, the screen name is provided only 
with the JSP name 103 of " Error. jsp" and thus control 
returns from step 503 to 502. If all filenames have been 
provided, the following processing will be performed. A 
s rvlet source code of "OrderServfetjava" is generated 
for the "New order screen", which is retrieved in step 
502 (step 504). Similarly, a JSP source code of "Order, 
jsp" is generated (step 505) and a Bean source code of 
"OrderBean.java" is then generated (step 506). It is de- 
t rmined whether processing has been performed on all 
screens of the component table 101 retrieved in step 

501 (step 507). If not, processing is repeated from step 

502 to 506 until alt screens are processed. When all 
screens have been processed, then control exits. 
[0078] Now, referring to Figs.6 and 7, a process flow 
is explained for automatically generating a servlet 
source code for the designated screen name. Upon gen- 
eration of a servlet source code, employed are a servtet 
template 701 , a package definition table 702, a compo- 
nent table 703, an error table 704, a form data specifi- 
cation 706, and a Bean public method table 707. Refer- 
ring to Fig.7, reference numeral 708 designates a serv- 
let source code to be generated. First, each of the 
names corresponding to the designated screen name 
102 is retrieved from the component table 101 (step 
601). An explanation is given here assuming that the 
screen name 102 designated is "New order screen*. 
"OrderServtetjava* of the servlet filename is employed 
as the filename of a source code 708 to create a file 
(step 602). Then, the servlet template 701 is read from 
the template data 208 (step 603). The template 701 de- 
scribes the basic frame of a servlet 

[0079] Then, the package definition table 702 is read 
from the design document 204 to generate a package 
statement 709 and an import statement 71 0 (step 604). 
A servlet package name is o inputted to the package 
statement 709, while a Bean package name is outputted 
to the import statement 71 0. The package declaration 
table 702 has the description of the package name of 
each component "OrderServlet" is retrieved from "Or- 
derservlet Java" of the servlet filename 104 as the class 
name to generate a class definition unit 711 (step 605). 
For example, "BaseServlet" 71 2 is generated as a su- 
perclass servlet that the "OrderServlet" inherits. The 
"BaseServlet" 712 is provided as a class to be used in 
the development support system according t this em- 
bodiment For example, "namesQ" 71 3 and a "business 



- — 0"717 ar a method defmed by th "BaseSen/l T'712' 
to be implem nted in a subclass. The "names ()" 713 is 
a method for setting the name of JSP, Bean class, and 
an error JSP, which are employed by the servlet, while 

5 the "businessQ" 717 is a method f r defining the con- 
tents of the processing performed by the servlet "Order, 
jsp" of the JSP name 1 03 retrieved in step 601 is gen- 
erated as a JSP 714 to be used (step 606), and "Order- 
Bean" 71 5 of the Bean class name to be used is re- 

10 trieved and outputted from the "OrderBean.java" of the 
Bean filename 105 (step 607). Then, the error table 704 
is read from the design document 204 to retrieve and 
generate an error JSP 716 corresponding to the "Or- 
derServiet Java" (step 608). The error table 704 assoct- 
ates each servtet filename 104 with each error JSP 
name, where a JSP is designated for displaying the error 
generated upon execution of the servlet. 
[0080] Subsequently, the contents of the processing 
of the "businessO" 717 are generated. A variable is set 

20 using the Bean class name employed which has been 
retrieved in step 607 (step 609). The "bean" is a variable 
defined in the superclass "BaseServlet" and is used by 
being cast to the Bean class used in the subclass. Then, 
the screen transition diagram 705 is read from the de- 

25 sign document 204 to search the original screen by 
screen name (step 61 0), and then the form data speci- 
fication 706 corresponding to the original screen is read 
from the design document 204 (step 611). When a re- 
quest is sent from the Web browser 302 to the server 

30 304, the information described in the form of the HTML 
page 303 is added to the request as input data The input 
data is designated in the form data specification 706. 
The Bean public method table 707 of the Bean class to 
be used is read from the design document 204 (step 

35 612), and then a parameter of posted form data is re- 
trieved to generate a code 71 8 for setting the parameter 
to the Bean to be used (step 613). The Bean public 
method table 707 is a list of all methods that are made 
public In the Bean class to be used, and defines access 

40 methods for input data described in the form data spec- 
ification 706. Then, it is checked whether the code 718 
has been generated to set parameters to all items de- 
scribed in the form data specification 706 (step 614). If 
not, the processing of step 61 3 is repeated until all items 

45 are processed. When all items have been processed, 
control exits from the definition of the *b us in ess ()" 717. 
Finally, the created file of the source code 708 is stored 
in the servlet source code data 209 (step 61 5), and then 
control exits from the processing for automatically gen- 

so erating the servlet source code. 

[0081] Referring to Fig.7, it has been explained that 
the "BaseServlet" 71 2 is provided as a superclass. Now, 
referring to Fig. 8, the source code of the superclass 
"BaseServlet" 712 is explained below. In Fig.B, refer- 

55 ence numeral 801 designates a source code and "Bas- 
eServlet" 802 shows the class name of the superclass. 
[0082] First, reference numeral 803 designates a dec- 
laration of variables, employed by the servlet, for dedar- 
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ingthe dSP nam , Bean class nam rerror JSP-name;- — 
and a Bean object to be used. Reference numerals 804 
to 81 1 designating th definition of methods are shown 
below. Methods "initO" 807 and "doPostf)" 809 are de- 
fin d by "HttpServlet" and implemented in this class. $ 
Method "businessO" 804 is overridden in the subclass 
and describes actual processing. Method "attribute 0" 
805 performs setting to allow JSP to access Bean, while 
method f orwardO" 806 calls JSP from the sen/let. Meth- 
od "doPostO" 809 determines the order of processing of 10 
the methods from 804 to 806 in order to allow the sub- 
class not to take the order of processing into constder- 
ati n. This obviates the necessity for a developer, who 
is to create the subclass, to have special knowledge on 
the sen/let. In addition, the "initO" 807 calls "namesO" 15 
808. The "namesO" 808 is defined as an abstract meth- 
od and implemented in the subclass. Referring back to 
Fig.7, as shown by 714 to 716, the JSP to be used in 
the sen/let and the Bean class are set. It is made pos- 
sible to create a sen/let which can be executed only by 20 
setting each name with the "namesO" 808. Method "er- 
rorfj" 810 defines processing to be performed on an er- 
ror occurring upon execution of the sen/let Access 
methods are defined below for the variables declared in 
th variable declaration 803. 25 
[0083] Now, referring to Figs.9 and 1 0, a process flow 
is explained for automatically generating a JSP source 
code for the designated screen name. Upon generation 
of a JSP source code, employed are a JSP template 
1001 , a screen image 1 002, a component table 1 003, a 30 
form data specification 1005, and an event specification 
1006. Referring to Fig. 10, reference numeral 1 007 des- 
ignates a JSP source code to be generated. 
[0084] First, each of the names associated with the 
designated screen name 1 02 is retrieved from the com- 35 
portent table 101 (step 901). An explanation is given 
here assuming that the screen name 1 02 designated is 
■New order screen". The JSP filename "Order.jsp" is 
employed as the filename of the source code 1007 to 
create a file (step 902). Then, the JSP template 1 001 is *> 
read from the template data 208 (step 903). The tem- 
plate 1 001 describes the basic frame of JSP. 
[0085] Then, the Bean class name 1 008 "OrderBean" 
is retrieved from the Bean filename 105 "OrderBean. 
Java* retrieved in step 901 and generated (step 904). A 
JSP syntax <jsp:useBean> 1 009 is to use the Bean 308 
in the JSP 309. A screen transition diagram 1 004 is read 
from the design document 204 to search a linked screen 
(step 905), and then ■OrderConfirmServtet" is set to a 
linked servtet 1010 based on the servlet filename 104 50 
"OrderConfirmServlet.java" of the linked screen (step 
906). Then, the event specification 1005 and the form 
data specification 1006 are read from the design docu- 
ment 204 (step 907), and an HTML file of the screen 
image 1002 is read (step 908). The event specification 55 
1005 describes the contents of the processing per- 
formed upon pushing buttons or selection of lists in con- 
junction with input check conditions. A linked servlet 
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1 01 0 determined in step* 906rand~the contents of the - 
event specification 1005 and form data specification 
1 006 upon which th contents f th HTML file read in 
step 908 are r fleeted ar generated (step 909). Finally, 
the created file of th source code 1 007 is stored in the 
JSP source code data 21 0 (step 91 0), and then control 
exits from the processing for automatically generating 
the JSP source code. 

[0086] Now, referring to Rgs.11 and 12, a process 
flow is explained for automatically generating a Bean 
source code for the designated screen name. Upon gen- 
eration of a Bean source code, employed are a Bean 
template 1201 , a package definition table 1202, a com- 
ponent table 1203, a class diagram 1204, a sequence 
diagram 1205, a Bean public method table 1206, and a 
form data specification 1207. Referring to Fig. 12, refer- 
ence numeral 1208 designates a Bean source code to 
be generated. 

[0087] First, each of the names associated with the 
designated screen name 1 02 is retrieved from the com- 
ponent table 101 (step 1101). An explanation is given 
here assuming that the screen name 1 02 designated is 
"New order screen". The Bean filename "OrderBean. 
java" is employed as the filename of the source code 
1208 to create a file (step 1102). Then, the Bean tem- 
plate 1201 is read from the template data 208 (step 
1 1 03). The template 1 201 describes the basic frame of 
Bean. 

[0088] Then , the package definition table 1 202 is read 
from the design document 204 to generate a package 
statement 1209 (step 1104). The Bean package name 
is generated in the package statement 1209. A class 
name "OrderBean" is retrieved from the Bean filename 
1 05 "OrderBean .java" to generate a class definition unit 
1210 (step 1 1 05). The class diagram 1 204 is read from 
the design document 204 to search the superclass Bean 
which the "OrderBean" inherits, and then generate the 
class name 1211 thereof (step 1106). Then, defined are 
the contents of the processing of "doBusinessO" 1212 
which is a method executed by a servlet. The sequence 
diagram 1205 is read from the design document 204 to 
define in accordance with the sequence diagram 1205 
and generate the "doBusiness 0 ' 121 2 (step 11 07). The 
class diagram 1 204 and the sequence diagram 1 205 are 
a document which is described in UML (Unified Mode- 
ling Language) notation. 

[0089] Then, the form data specification 1 207 and the 
Bean public method table 1 206 are read from the design 
document 204 (step 1108), and variable declarations 
1213 are generated for all items described in the form 
data specification 1207 (step 1109) to define and gen- 
erate all methods of the Bean public method table 1 206 
(step 1110). Finally, the created file of the source code 
1208 is stored in the Bean source code data 211 (step 
1112), and then control exits from the processing for au- 
tomatically generating the Bean source code. 
[0090] Referring to Fig.1 3, it will be explained that the 
Bean is a component that is provided with all pieces of 
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inf rmati rr necessary forscreen display: -Rg.1 3 is~a 
view depicting the relationship between the screen in- 
formation and Bean. In Fig. 13, reference num ral 1301 
designates a screen image and an explanation is given 
to an xample of "New order confirm screen". Reference 
numeral 1302 designates the class of Bean. The name 
displayed in a partition 1303 above the class 1302 is a 
class name, showing that the ■OrderConfirrnBean" cor- 
responding to the "New order confirm screen" is the 
class name of the Bean. A lower partition 1304 indicates 
th attribute of the class. The ■OrderConfirmBean - is 
provided with all pieces of information necessary to dis- 
play the "New order confirm screen", the information be- 
ing retrieved by JSP and displayed as an HTML page. 
The information which is necessary for screen display 
and inputted to the form is defined in the form data spec- 
ification 1 207 and the Bean public method table 1 206 of 
Fig.12. 

[0091 ] Now, a second embodiment of the present in- 
vention is explained below. Here, an example is ex- 
plained which employs a servtet, JSP, and Bean, de- 
scribed later with reference to Rg.1 4, for designing and 
developing a Web application system. In particular, the 
present invention is characterized in that the name of 
each component of the servtet, JSP, and Bean is defined 
by being associated wfth each screen in the screen 
specification provided by design information. Using the 
component definition and the contents of the design in- 
f rmation, the definition of methods and the call relation- 
ship between the components are automatically extract- 
ed to automatically generate source codes. 
[0092] Fig. 14 is a view depicting an example of the 
overall configuration of a Web application system which 
employs the servtet, JSP, and Bean, designed and de- 
veloped in this embodiment This Web application sys- 
tem is used by a Web browser 1402 on a client 1401. A 
HTM L page 1 403 appears on the Web browser 1 402. A 
request from the Web browser 1402 is sent to a server 
1 404 via HTTP. The server 1 404 is provided with a HTTP 
server 1405 and an application server 1406, while the 
application server 1 406 includes a runtime environment 
of a servtet and JSP. 

[0093] A servtet 1407, JSP 1408, and Bean 1409 are 
arranged on the application server 1406 of the server 
1 404. A request sent from the Web browser 1 402 of the 
client 1 401 will cause the corresponding servlet 1407 to 
be activated in accordance with the request. The servlet 
1407 issues a request to the corresponding Bean 1409 
t perform processing. In addition, the Bean 1 409 uses 
a business class and DB access class 1410 to access 
a database 1411, then performing data manipulation 
necessary for business transactions to execute busi- 
ness transactions and data processing. The Bean 1 409 
holds the resulting data. The business class and the DB 
access class 1410 represent a class created through the 
analysis and design of business rules or a reusable ex- 
isting class. Then, the servlet 1407 passes the Bean 
1409 to the JSP 1408, calls the JSP 1408, and issues 



a request ther to t generate arrHTMt pager The'JSP™ 

1408 retrieves the resulting data held in the Bean 1409 
to generate an HTML page and s nditbackt th cli nt 
1401 . The HTML page 1 403, which has been sent back, 

s is displayed on the Web browser 1 402. 

[0094] As described above, the servlet 1 407 receives 
the request from the Web browser 1402, issues a re- 
quest to the Bean 1409, and calls the JSP 1408, thus 
serving to connect between and control each of them. 

10 The JSP 1 408 serves to display the output of an HTML 
page, while the Bean 1409 serves to assemble business 
using the business class and the DB access class 1 41 0, 
execute actual processing, and hold the resulting data. 
Their respective roles are dearly separated, thereby a\- 

is lowing each of their functions to be grasped in a simple 
manner. 

[0095] Rg.1 5 depicts the relationship between some 
recipient components and response components, em- 
ployed in a Web application system according to this 

20 embodiment An input screen 1 51 0 shows a screen for 
sending a request to the server 1404. The request is 
processed on the server and the resulting data is sent 
back to the client 1401 as an output screen 1504. In Fig. 
14, the servlet 1407 corresponds to a recipient compo- 

25 nent 1502, while the JSP 1408 corresponds to a re- 
sponse component 1503. Fig. 14 shows the configura- 
tion of a Web application system employing the servtet, 
JSP, and Bean. It is also possible to receive a request 
from the Web browser 1 402 and send back the resulting 

30 data thereto only with the servlet 1 407 or only with the 
JSP 1408, without using the JSP 1408 and the Bean 
1409. Preparation of recipient window parts 1 (1505) 
and response window parts 1 (1506) allows the received 
request to be assigned to a corresponding recipient part 

35 or the resulting data to be assigned to a corresponding 
response part Accordingly, recipient components and 
response components are not always associated with 
each other in a one-to-one relationship. Components 
should be defined by selecting an appropriate relatton- 

40 ship in accordance with the configuration of the Web ap- 
plication system to be developed. Here, an explanation 
is given to such a case where a recipient component 
and response component are associated with each oth- 
er in a one-to-one relationship such as a recipient part 

45 7 (1507) and response part 7 (1508). 

[0096] Figs. 16 and 17 show examples of defining a 
one-to-one relationship between the recipient compo- 
nent 1502 and the response component 1503. An event 
1 601 shows, for example, the pushing a button upon 

so sending a request from the input screen 1501 to the 
server. A condition 1 62 is applied to the call made by 
the recipient component 1502 to the response compo- 
nent 1 503 as a result of processing on the server. As an 
exception, when the condition 1 62 is set, the recipient 

55 component 1 502 and the response component 1 503 are 
associated with each other in a one-to-one relationship. 
[0097] In Rg.16, the recipient component 1502forrer 
ceiving a request from the input screen 1501 depends 
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• rr the output screen - 1 504; The recipient* component 

1502 and the response component 1503 ar created 
corresponding t th output screen 1504, considering 
that the request from the input screen 1501 is to output 
th subsequent output screen 1504. A screen C 1603 5 
of the input screen 1501 includes a recipient component 

1502 for sending a request, which is different depending 
on the event 1601. 

[0098] On the other hand, in Fig. 1 7, the recipient com- 
ponent 1 502 depend on the input screen 1 501 . The re- 1 o 
quest from the input screen 1 501 is received by the cor- 
responding recipient component 1502. The recipient 
component 1502 assigns the response component 

1503 in accordance with the event 1601 and condition 
162. The recipient component 1502 and the response 15 
component 1 503 are created corresponding to the input 
screen 1501 and the output screen 1504, respectively. 

A plurality of events 1601 , such as on a screen C 1 701 
of the input screen 1 501 , will be received and processed 
by a corresponding recipient component 1502. Given 20 
below Is an explanation of the definition of the relation- 
ship between components shown in Rg.16. 
[0099] Fig. 1 8 depicts an example of the definition, ex- 
pressed in a tabular form, of the relationship among the 
screen name, servtet, JSP, and Bean of the Web appli- 25 
cation system which is designed and developed in this 
embodiment. A component definition table 1 801 con- 
sists of a screen name 1802, a screen ID 1803, a servtet 
name 1 804, a Bean name 1 805, and a JSP name 1 806, 
and defines names corresponding to each screen in> 30 
age. The screen name 1802 represents the name of a 
screen to be generated by a component with a combi- 
nation of the servtet name 1804, the Bean name 1805, 
and the JSP name 1 806. A servtet given by the servtet 
name 1804 is the recipient component 1502, while a 35 
JSP given by the JSP name 1808 is the response com- 
ponent 1503. 

A Bean given by the Bean name 1805 is a component 
which executes the processing requested by the servtet 
and of which information is retrieved by the JSP upon *o 
generation of an HTML page. 

[0100] The servtet name 1804 and the Bean name 
1805 are not supplied with an extension sign and the 
name of a class f ile, whereas the JSP name 1 806 is sup- 
plied with an extension sign of ".jsp". For example, for 45 
the screen name 1802 Top" 1807, the servlet name 
1804 is "DefauttServlef in which the screen ID 1803 
"default" with the first character being written with its up- 
per-case letter is added by "Servtet". Similarly, the Bean 
name 1 805 is "Def aultBean" in which the screen ID 1 803 so 
"default" with the first character being written with its up- 
per-case letter is added by "Bean". The JSP name 1 806 
is "defautt.jsp" in which the screen ID 1803 is supplied 
with an extension sign of ".jsp". 

[01 01 ] In some cases, the servlet name 1 804 and the 55 
Bean name 1805, or the JSP name 1806 and the Bean 
name 1 805 are associated with each other in an n-to-m 
relationship such as "Order confirm" 1809. In this case, 



the B an name 1805 cannot be - defined on th screerr" 
ID 1803, and therefore edited for addition. Furthermore, 
for "Error display" 1810, only "enor.jsp" 1811 of the JSP 
name 1806 is defined. This is called by some sen/lets. 
Given below is an explanation of a one-to-on r lation- 
ship among the servlet name 1804, the Bean name 
1805, and the JSP name 1806. 
[01 02] A component definition table 1 901 depicted in 
Fig. 19 shows an example of the definition of a one-to- 
one relationship among the servlet name 1804, the 
Bean name 1 805, and the JSP name 1 806, correspond- 
ing to each screen name 1 802. 
[01 03] Fig.20 depicts an example of the configuration 
of a system for designing and developing a Web appli- 
cation system. In Fig.20, reference numeral 2001 des- 
ignates a terminal for the input of commands and oper- 
ation with a mouse; reference numeral 2002 designates 
a central processing unit for implementing various func- 
tionality, described later; and reference numeral 2003 
designates an external storage unit for storing various 
pieces of information. A design document 2004 stored 
in the external storage unit 2003 includes a design doc- 
ument such as GUI specifications to be obtained from 
the requirements and business specification provided 
by customers for the development of a Web application 
system, and HTML files representative of screen design 
and each screen image. Component definition data 
2005 include the component definition table 1901 de- 
picted in Fig. 19. Template data 2006 include templates 
employed upon generation of the source code of each 
component, source codes or superclasses of servlet 
and Bean, and class files. Source code data 2007 in- 
clude the source codes of the servlet, JSP, and Bean. 
[01 04] The central processing unit 2002 includes and 
executes software which implements the following three 
functions. A component definition generating/editing 
unft 2008 reads design information from the GUI spec- 
ification stored in design document 2004 to generate 
and store in the component definition data 2005 the 
component definition table 1901 for defining the rela- 
tionship among the screen, servlet, JSP, and Bean. Fur- 
thermore, it is possible to edit the generated component 
definition table 1 901 on a terminal 2001 using the com- 
ponent definition generating/editing unit 2008. A code 
generating unit 2009 generates automatically the 
source code of each of the servlet, JSP, and Bean, using 
the component definition table 1901 stored in the com- 
ponent definition data 2005 and the design document 
2004 such as the GUI specification or the system design 
document. Upon generation of source codes, used are 
the template and superclass of each of the components 
stored in the component definition data 2005. Each 
source code generated in the code generating unit 2009 
is stored in the source code data 2007. Using the com- 
ponent definition table 1901 stored in the component 
definition data 2005, a code editing unit 201 0 retrieves 
the source code of each component corresponding to 
the screen to be developed from the source code data 
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2007 1 edrtth source code on fret rmmat 2001 using 

an editor. 

[0105] Fig.21 depicts an exampl fadev loping pro- 
cedure for designing and developing a Web application 
system according t this embodim nt. First, a servlet is 5 
created and then a Bean and a JSP are created in that 
order. In the creation of the servlet, a servlet source code 
21 08 is created using design information 21 02 with ref- 
erence to a servlet template 21 01 . For example, the de- 
sign information 21 02 necessary for creating the servlet 10 
includes the component definition table 1 901 , a pack- 
age specification 2104, a screen transition diagram 
2105, a form data specification 2106. a session man- 
agement specification 2107, and an error specification 
2108. « 
[0106] The package specification 21 04 describes the 
definition and name of each component The screen 
transition diagram 2105 shows the transition between 
screens. Upon sending a request from a Web browser 
to a server, the contents described in the form of an 20 
HTML page are added to the form data. The contents 
of the form data are described in the form data specifi- 
cation 2106. The session management specification 
2107 descrfoes the information that is taken over be- 
tween the screens. The error specification 2108 de- 25 
scribes the contents of the processing that is performed 
when an error has occurred as a result of processing on 
the server. 

[0107] Subsequently, the Bean is created. Upon cre- 
ation of the Bean, a Bean source code 2111 is created 30 
using design information 2110 with reference to a Bean 
template 2109. For example, the design information 
21 1 0 necessary for creating the Bean includes the com- 
ponent definition table 1901 , the package specification 
21 04, the screen transition diagram 21 05, the form data 35 
specification 2106, a check list 2112, a class specifica- 
tion 21 1 3, a method specification 21 1 4, and a sequence 
diagram 2115. 

[0108] The check Bst 2112 descrtoes items such as a 
value check or validity check of the form data provided *o 
when a request is sent. The class specification 21 1 3 de- 
scribes the Bean, a business class of Fig. 14, the class 
diagram of the DB access class 1410, and the outline, 
/ attribute and method of a class. The method specifica- 
tion 21 1 4 describes in detail the method provided by the 43 
class of the class specification 2113. The sequence di- 
agram 2115 shows in a diagram the flow of method 
processing. The class diagram of the class specification 
2113 and the sequence diagram 2115 are a document 
which is described in UML (Unified Modeling Language) so 
notation. 

[0109] Finally, the JSP is created. Upon creation of 
the JS P, a JSP source code 21 1 8 is created using design 
information 21 1 7 with reference to a JSP template 211 6. 
For example, the design information 2117 necessary for 55 
creating the JSP includes the component definition table 
1901, a screen image 2119, the screen transition dia- 
gram 2105, an event specification 2120, the form data 



specification 21 06, the class specification 21 13, and the" 
method specification 2114. 

[0110] The screen image 2119 defines the image of 
each screen of the GUI specification and is created in 
an HTML fil . The event specification 2120 describes 
the check items or processing on the client to check in- 
puts such as pushing buttons or selection of lists in an 
HTML page form. 

[01 1 1 ] The system according to this embodiment al- 
lows the code generating unit 2009 to automatically gen- 
erate each of source codes 21 03, 21 1 1 , 21 1 8 of the serv- 
let, JSP, and Bean, which are in turn stored as the 
source code data 2007 in the external storage unit 2003. 
In addition, the code editing unit 201 0 is used to edit the 
source codes. 

[01 12] The flow of processing for generating the com- 
ponent definition table 1901 with the component defini- 
tion generating/editing unit 2008 is explained below with 
reference to Fig.22. First, all pieces of screen informa- 
tion are read from the GUI specification stored in the 
design document 2004 (step 2201). The screen name 
and ID are retrieved from the first screen information 
(step 2202). For example, the screen ID may be re- 
trieved from the filename of each HTML file prepared as 
a screen image or may be defined in the screen infor- 
mation. Alternatively, the screen ID may be entered on 
the terminal 2001 for each screen. Here, an explanation 
is given assuming that the retrieved screen name is "Or- 
der confirm" and the screen ID is "confirm". 
[0113] Then, the retrieved screen ID with the first 
character being written with its upper-case letter is add- 
ed by 'Servlet" to form a servlet name (step 2203). Sim- 
ilarly, the screen ID with the first character being written 
with its upper-case letter is added by "Bean" to form a 
Bean name (step 2204). The screen ID is supplied with 
an extension sign of ".jsp" to form a JSP filename (step 
2205). Thus, the name of each of the components is de- 
fined as "ConfirmServlet", "ConfirmBean", and "confirm, 
jsp", respectively. A set of the screen name, the screen 
ID, and the defined servlet name, Bean name, and JSP 
name is added to the component definition table 1901 
(step 2206). 

[01 1 4] Then , it is checked whether al I pieces of screen 
information retrieved in step 2201 have been processed 
(step 2207). If not, control returns so as to repeat the 
processing from step 2202 to 2206 until all screen infor- 
mation has been processed. Finally, if all pieces of 
screen information have been processed, the compo- 
nent definition table 1901 is stored in the component 
definition data 2005 and then control exits (step 2208). 
Here, the generated component definition table 1901 
may be stored in the design document 2004. 
[0115] Now, referring to Fig.23, a process flow is ex- 
plained for automatically generating each source code 
of the servlet, JSP, and Bean in the code generating unit 
2009. First, the component definition table 1901 gener- 
ated by the component definition generating/editing unit 
2008 is read (step 2301). The screen name 1802 is re- 
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-trieved from thecomponent definitiontabl 190 instep- 
2302). An xplanation is given h re assuming that th 
screen nam retrieved is "Order confirm". Th nam of 
each component corresponding to the screen name is 
retrieved (step 2303). it is checked whether all of the 
serviet name 1804, Bean name 1805, and JSP name 
1 808 have been set corresponding to the screen name 
retrieved (step 2304). Take the "Error display" 1811 in 
Fig. 19 as an example. Here, the screen name is provid- 
ed only with the JSP name 1806 "error.jsp" and thus 
control returns from step 2304 to 2302. If all names have 
been set, the following processing will be performed. 
[01 1 6] First, a serviet source code of "ConfirmServiet. 
java" is generated for the "Order confirm", which is re- 
trieved in step 2302 (step 2305). Similarly, a Bean 
source code of "ConfirmBean.java" is generated (step 
2306) and a JSP source code of "confirm.Jsp" is then 
generated (step 2307). ft is determined whether 
processing has been performed on all screen names of 
the component definition tabie 1 901 that has been read 
in step 2301 (step 2307). If not, processing is repeated 
from step 2302 to 2307 untfl all screen names have been 
processed. When all screen names have been proc- 
essed, then control exits. Incidentally, in the foregoing, 
th source codes are generated after it is checked in 
step 2304 that all of the serviet name 1 804, Bean name 
1 805, and JSP name 1 806 have been set corresponding 
to the screen name. However, the check in step 2304 is 
not always inevitable. If any one of the serviet name 
1804, Bean name 1805, and JSP name 1806 has been 
set, its source code may be generated. 
[0117] Now, referring to Figs.24 and 25, a process 
flow is explained for automatically generating a serviet 
source code for the designated screen name in the code 
generating unit 2009. ft is assumed that the name of 
each component defined in the component definition ta- 
ble 1901 is given in advance. An explanation is given 
here assuming that the screen name 1 802 designated 
is "Order confirm" and the names of the components are 
"ConfirmServiet", "ConfirmBean", and "confirm.Jsp", re- 
spectively. Upon generation of a serviet source code, 
employed are the serviet template 21 01 , the component 
definition table 1901 from the design document stored 
in the design document 2004, the package specification 
21 04, the screen transition diagram 21 05, the form data 
specification 21 06, the session management specif ica- 
tion 2107, and the error specification 2108. Referring to 
Fig.25, reference numeral 2501 designates a serviet 
source code to be generated. 

[0118] First, created is a file "ConfirmServiet. java" 
with the filename of the given serviet name 1804 and 
with an extension sign of "Java" (step 2401). Then, a 
serviet template list is read from the template data 2006 
(step 2402). The template data 2006 stores the basic 
frame of a serviet as well as serviet templates for various 
use and superclasses. Then, the template 2101 for use 
with the serviet to be created is selected from the tem- 
plate list that has been read (step 2403). The selected 



~ template 21 01 is used as a model f rcreatingthesource- 

code 2501. Her , in some cases, the employed template 
2101 may be individually selected or may hav already 
been set 

5 [0119] Then, the packag specification 2104 is read 
to generate a package statement 2502 and an import 
statement 2503 (step 2404). The serviet package name 
is outputted to the package statement 2502, while the 
Bean package name is outputted to the import state- 

10 ment 2503. Then, the serviet name 1 804 ■ConfirmServ- 
iet" is employed as the class name and outputted to a 
class declaration 2504 (step 2405). A "serviceO" 2505 
is a method provided by the_ serviet API and would be 
executed in accordance with the request from a client. 

is in the subsequent processing, the contents of the 
processing of the 'serviceO" 2505 are generated. 
[0120] First, the given Bean name 1805 "Confirm- 
Bean" is generated from the serviet and outputted as a 
Bean class name 2506 to be used (step 2406). Trie orig- 

20 inal screen is searched in the screen transition diagram 

2105 (step 2407). Then, the form data specification 

2106 of the original screen is read as an item name 2507 
for use upon retrieval of a parameter, the parameter be- 
ing then retrieved and set to the Bean (step 2408). Sub- 

25 sequentty, the session management specification 21 07 
is read (step 2409) to generate an item name 2508 of 
the parameter retrieved from the session (step 241 0). 
[01 21 ] Similarly, the parameter to be stored in the ses- 
sion and an item name 251 0 are generated (step 241 1 ). 

30 A method "doTaskO" 2509 is used to issue a request 
from the serviet to the Bean for processing. Then, the 
error specification 21 08 is read to generate the contents 
of the processing upon occurrence of an error (step 
241 2). At the end of the "serviceO" 2505, the given JSP 

35 name 1806 "confirm.Jsp" is generated as a JSP name 
2512 to be called from the serviet (step 2413). Finally, 
the file of the generated source code 2501 is stored in 
the source code data 2007, and then control exits from 
the processing for automatically generating the serviet 

40 source code (step 241 4). 

[0122] Figs.24 and 25 show examples for generating 
the serviet source code. In these examples, the tem- 
plate 21 01 is employed as a model for automatically ex- 
tracting and generating necessary items from the con- 

45 tents of the design document 2004 to output the items 
where appropriate. Now, referring to Rg.26, it will be ex- 
plained below that source codes can also be generated 
by inheriting as a template a superclass prepared as a 
class to be used in the development system according 

50 to this embodiment. In Rg.26, reference numeral 2601 
designates a serviet source code to be generated. Since 
most of common processing is defined in a superclass, 
only unimplemented or insufficient processing may be 
developed. In addition, the source code 2601 of Rg.26 

55 can be generated more easily than the source code 
2501 of Fig.25. 

[0123] When a source code is created by inheriting a 
superclass, a superclass is selected in step 2403 of Fig. 
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-24 forthetemplat 2101-torbe userf.Therr.th super- 
class is outputted to a superclass name 2602, which in- 
herits the superclass, upon outputting th class decla- 
ration in step 2405. Most of processing is implemented 
in the superclass of the servtet, for example, methods 
"initO" 2603, "beforeTaskO" 2604, and "afterTaskO" 
2605 are only declared. These methods 2603, 2604, 
2605 are defined in the subclass. The method "initO" 
2603 carries out setting upon initialization and desig- 
nates the Bean name or JSP name, which are to be used 
or called by the servtet, using "setBeanNameO" 2606 ° r 
"setJspPageO" 2607. Then, the contents of the process- 
ing to be performed before the Bean is requested for 
processing are implemented in the "beforeTaskO' 2604, 
whereas the contents of the processing to be performed 
after the Bean has performed processing are imple- 
m nted in the "afterTaskO" 2605. For example, session 
management is carried out here. As described above, 
developers can develop a servlet only by Implementing 
the InitO" 2603, the "bef oreTaskO" 2604, and the •after- 
TaskO" 2605. 

[0124] In Fig.26, it has been explained above that 
source codes can be generated by inheriting as a tem- 
plate a superclass prepared as a class to be used in the 
development system according to this embodiment 
Now, referring to Fig.27, an example of a superclass 
source code is explained below. In Rg.27, reference nu- 
meral 2701 designates a superclass source code and a 
class name 2702 is "BaseServiet". 
[0125] First, reference numeral 2703 is the declara- 
tion of a variable employed in the "BaseServiet", which 
declares the JSP name, the Bean name, and the Bean 
object to be used. Reference numerals 2704 to 2712 
designate the definition of methods below. A method "in- 
itO" 2704 carries out setting upon initialization and is im- 
plemented in the subclass to set the Bean name and 
JSP name, which are used or caOed by the servlet. A 
method "serviceO" 2705 is provided by the servlet API 
and will be executed when required by a client. In the 
"serviceO" 2705, the methods from 2707 to 271 2 are ex- 
ecuted in the predetermined order. For this reason, the 
subclass that inherits the superclass "BaseServiet" 
2702 has no need to take the order of processing into 
consideration. This obviates the necessity for a devel- 
oper, who is to create the subclass, to have special 
knowledge on the servlet Definition of the "initO" 2704 
in the subclass would make it possible to create an ex- 
ecutable servlet. 

[0126] A method "createO" 2706 creates an object 
with the designated Bean name, while a method 
"doTaskO" 2708 issues a request to the Bean for 
processing. The processing before and after the 
"doTaskO" 2708 is described in methods "beforeTaskO 
■ 2707 and "afterTaskO" 2709, respectively, and is im- 
plemented in the subclass if necessary. A method "cal- 
UspO" 2710 calls the JSP of the JSP name designated. 
Occurrence of an exception while the "serviceO" 2705 
is being executed would cause a method "errorQ" 271 1 



- to execute error processing;* Reference num ral 2712- - 

is the definition of an access method for a variable 2703 
mployed in the "BaseServiet". 
[0127] When a servlet source code is automatically 

5 generated in the code generating unit 2009, a template 
is selected corresponding to the servlet to be created. 
An example of a method for selecting the template is 
explained below with reference to Fig. 28. In Fig .28, ref- 
erence numeral 2801 designates an operation screen 

io for a development support system according to this em- 
bodiment In a region 2802 to the left of the screen, dis- 
played is a system name of an "Order system" 2803 
which is to be designed and developed. In a hierarchical 
structure provided just below the "Order system", a 

15 screen name "Order confirm" 2804 is displayed and fol- 
lowed by the servlet, JSP, and Bean in sequence. This 
hierarchical structure represents the contents of the 
component definition table 1901 that is defined by the 
component definition generating/editing unit 2008. 

20 [0128] Here, an explanation is given to a case where 
a template is selected for use in generating "Confirm- 
Servtet" 2805 of the servlet Reference numeral 2806 
designates a template selection screen for allowing a 
template of the servtet to be selected, where the tem- 

25 plate list read from the template data 2006 is displayed 
in list form. The list displayed includes a name 2807 in- 
dicating the template and a code name 2808. Selection 
of a template to execute an execution button 2809 on 
the template selection screen 2806 will make the select- 

30 ed template available. In addition, the execution of a 
contents explanation button 281 0 would cause a screen 
2811 to be displayed, in which the template selected is 
explained in detail. 

[0129] Like the servlet, a template is selected and 

35 used as a model upon generation of Bean and JSP 
source codes, which is described with reference to Figs. 
30 and 33. Referring to Fig.29, explained is an example 
of a method for selecting each of the Bean and JSP tem- 
plates. Like the template selection screen 2806 of Fig. 

40 28, there are provided a Bean template selection screen 
2901 and a JSP template selection screen 2904. In the 
list displayed on each screen, displayed are template 
names 2902, 2905 and code names 2903, 2906. In the 
Bean template selection screen 2901 , shown is the con- 

45 figuration of classes in a class hierarchy. In addition, in 
the JSP template selection screen 2904, a plurality of 
templates or a combination of templates can be used. 
[0130] Now, referring to Figs.30 and 31, a process 
flow is explained for automatically generating a Bean 

50 source code for the designated screen name in the code 
generating unit 2009. It is assumed that the name of 
each component defined in the component definition ta- 
ble 1 901 is given in advance. An explanation is given 
here assuming that the screen name 1 802 designated 

55 is "Order confirm" and the name of the component is 
"ConfirmBean". Upon generation of a Bean source 
code, employed are the Bean template 2109, the com- 
ponent definition table 1901 , the package specification 



13 



25 



EP 1 139 216 A2 



26 



2104 from the* design docarnent'storechinrthe* desigrr- 
document 2004, the screen transition diagram 21 05, the 
form data specif ication 21 06, th check list 2112, th 
class specification 21 1 3, the method specif ication 2114, 
and sequence diagram 2115. Referring to F*ig.31 , refer- 
ence numeral 31 01 designates a Bean source code to 
be generated. 

[01 31 ] First, created is a file "ConfirmBean Java" with 
the filename of the given Bean name 1 805 employed as 
the filename and with an extension sign of "Java" (step 
3001 ). Then, a Bean template list is read from the tem- 
plate data 2006 (step 3002). Like the servlet template, 
the template data 2006 stores the basic frame of a Bean 
as well as Bean templates for various use and super- 
classes. Then, the template 21 09 for use with the Bean 
to be created is selected from the template list that has 
been read (step 3003). The selected template 2109 Is 
used as a model for creating the source code 3101 . 
[0132] Then, the package specification 21 04 is read 
to generate the package statement 3102 (step 3004). 
The Bean package name is generated in the package 
statement 31 02. Then, the Bean name 1 805 "Confirm- 
Bean" is employed as the class name and outputted to 
a class declaration 3103 (step 3005). Furthermore, the 
class specification 2113 is searched for the superclass 
of the target Bean class "ConfirmBean" to generate the 
name (step 3006). 

[01 33] A method "doTaskO" 31 04 is executed by the 
servlet and the contents of the processing 31 05 are im- 
plemented here with the Bean. Then, the sequence di- 
agram 2115 is read to output the contents of the 
processing in accordance with the sequence diagram 
21 15 (step 3007). Then, the contents of the processing 
of a method "checkQ* 31 06 are generated. The "check 
0" 3106 is called from the "doTaskO" 3104 to check the 
parameter passed from the servlet First, the original 
screen is searched in the screen transition diagram 

2105 (step 3008). Then, the form data specification 

21 06 of the original screen is read to generate an item 
name 31 07 for use upon retrieval of a parameter (step 
3009). The check list 2112 is read to generate check 
processing 31 08 for checking the parameter generated 
in step 3009 (step 3010). 

[0134] Then, the attribute of the target Bean class 
"ConfirmBean" is retrieved from the class specification 
2113 to generate a declaration 3109 of the attribute 
(step 3011). Then, generated are a retrieval method for 
retrieving and a setting method 3110 for setting the at- 
tribute (step 3012). Furthermore, the method specifica- 
tion 2114 is read to generate methods other than the 
"doTaskO" 31 04, the "check()" 31 06, the attribute setting 
method, and the attribute retrieval method 3110 (step 
3013). Finally, the file of the generated source code 
3101 is stored in the source code data 2007, and then 
control exits from the processing for automatically gen- 
erating the Bean source code (step 3014). 
[0135] Now, referring to Fig. 32, it will be explained 
that the Bean is a component that is provided with all 



pieces of information necessary forscreendisplay.'Fig: — 

32 is a view depicting trie relationship between the 
screen information and Bean. In Ftg.32, reference nu- 
meral 3201 designates a screen image and an explana- 

5 tion is given to an exampl of "Order confirm" screen. 
Reference numeral 3202 designates the class of Bean. 
The name displayed in a partition 3203 above the class 
3202 is a class name, showing that the "ConfirmBean" 
corresponding to the "Order confirm" is the class name 

10 of the Bean. A lower partition 3204 indicates the attribute 
of the class. The "ConfirmBean" is provided as attributes 
with ail pieces of information necessary to display the 
"Order confirm" screen, those attributes being retrieved 
by JSP and displayed as an HTML page. The informa- 

is tion which is necessary for screen display and entered 
to the form of the HTML page is described in the form 
data specification 2106 of the design document stored 
in the design document 2004. 
[0136] Now, referring to Figs.33 and 34, a process 

20 flow is explained for automatically generating a JSP 
source code forthe designated screen name in the code 
generating unit 2009. It is assumed that the name of 
each component defined in the component definition ta- 
ble 1901 is given in advance. An explanation is given 

25 here assuming that the screen name 1 802 designated 
is "Order confirm", and the name of the Bean and JSP 
components is "ConfirmBean" and "confirm .jsp", re- 
spectively Upon generation of a JSP source code, em- 
ployed are the JSP template, the component definition 

30 table 1 901 , the screen image 211 9 from the design doc- 
ument stored in the design document 2004, the screen 
transition diagram 2105, the event specification 2120, 
the form data specification 21 06, the class specification 
2113, and the method specification 2114. Referring to 

35 Fig.34, reference numeral 3401 designates a JSP 
source code to be generated. 
[0137] First, created is a tile "Confirm.jsp" with the 
filename of the given JSP name 1806 employed as the 
filename (step 3301 ). The HTML file of the screen image 

40 211 9 of the "Order confirm" screen is read from the de- 
sign document (step 3302), and then the contents of the 
HTML file that has been read are generated (step 3303). 
Then, a JSP template list is read from the template data 
2006 (step 3304). The template data 2006 stores the 

45 basic framework of a JSP as well as JSP templates for 
various use. Then, the template 2116 for use with the 
JSP to be created is selected from the template list that 
has been read (step 3305). The selected template 211 6 
is used as a model for creating a source code 3401 by 

so processing the contents of the HTML file generated in 
step 3303. 

[0138] Then, the Bean name 1805 "ConfirmBean" 
given is generated as a class 3402 to be used in JSP 
(step 3306). Tag <jsp:useBean> 3402 is a syntax for us- 
55 jng the Bean in JSP. The event specification 2120 is read 
to generate a script definition 3403 for check items em- 
ployed by a client (step 3307). Then, the original screen 
is searched in the screen transition diagram 2105 (step 
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-3308); Thervth -component-definition- tabl "190t"is 

searched for the servtet name 1804 corresponding to 
the original screen to output to a form tag action attribute 
3404 (step 3309). Then, the form data specification 
2106 is read to generate th text nt red into th form 5 
or names 3405 of parts such as buttons (step 3310). 
Then, the class specification 2113 is read to output the 
attribute name of the Bean, using the syntax of the JSP, 
to the parameter of the parts or the text in the form where 
appropriate (step 3311). Like in step 3311 , the method *0 
specification 2114 is read to output it using the method 
of the Bean where appropriate (step 3312). A tag <jsp: 
getProperty> 3406 and a tag <%=%> 3407 are a JSP „ 
syntax like the tag <jsp:useBean> 3402. Finally, the file 
of the generated source code 3401 is stored in the 
source code data 2007, and then control exits from the 
processing for automatically generating the JSP source 
code (step 3313). 
, [0139] Now, referring to Fig.35, an explanation is giv- 
n to an example of a method for editing the source code so 
of each component of the servtet, JSP, and Bean, in the 
code editing unit 2010. In Fig.35, reference numeral 
2801 designates an operation screen of the develop- 
ment support system according to this embodiment In 
the region 2802 to the left of the screen, displayed are 25 
the contents of the component definition table 1 901 in 
a hierarchical structure. Here, suppose that the "Order 
confirm 11 2804 is selected and double-clicked. In this 
case, the editor will be opened on the region to the right 
of the screen to show the source code of each compo- 30 
nent for the "Order confirm" 2804. The servtet source 
code "ConfirmServletjava" is opened on an editor 
screen 3504. Likewise, the Bean source code "Confirm- 
Bean.java" is opened on the editor screen 3503, while 
th JSP source code "confirm. jsp" is opened on the ed- 35 
itor screen 3504. Upon opening each source code, the 
s urce code of each component to be edited is read 
from the source code data 2007, using the component 
definition table 1 901 . In addition, the "ConfirmServlet" 
2805 can be selected alone to open the "ConfirmServlet 40 
java". This makes it possible for the developer to instan- 
taneously select and open the source code related to 
th screen to be developed, by selecting the screen 
name, allowing for retrieving or editing the source code. 
[01 40] As described above, the present invention pro- 45 
vides the following effects. 

(1) Only a design document is described to create 
the component table of the name of each compo- 
nent. This makes it possible to facilitate develop* 50 
ment of a system and alleviate the burden on de- 
velopers or programmers, thereby providing a re- 
duction in development time. 

(2) Relationship among the components of the serv- 
tet, JSP, and Bean for each screen is made clear 55 
and their respective roles are separately organized, 
thereby making it possible to develop each screen 
independently. 



— ~ (3) The source code of each coTnpoTTentcarrbe au- 
tomatically general d and thereby no special 
knowledge on Java is required. This makes it pos- 
sible to facilitate programming and thereby alleviate 
the burden on developers or programmers. Source 
codes are automatically generated in a standard- 
ized uniform fashion by the automatic code gener- 
ating unit. This facilitates maintenance and makes 
it possible to provide programs, the performance of 
which wilt not be degraded but guaranteed. 

(4) Addition, extension, or modification of functions 
for upgrading the system would require only a new 
definition or addition of each component of the serv- 
tet, JSP, and Bean, or easy identification of compo- 
nents to be modified or those within the known 
range of modification. This makes it possible to im- 
plement an extensible system. Furthermore, it can 
be safely said that what the development support 
system according to the present invention provides 
is the framework of a Web application system con- 
figured by the servtet, JSP, and Bean. 

(5) Upon development of a Web application system, 
each component can be defined by determining the 
GUI specification. This makes it possible to provide 
prototype or executable programs quickly, thereby 
allowing actual test of the architecture of the system 
at earlier time. 

[0141] While there has been described what are at 
present considered to be preferred embodiments of the 
present invention, it will be understood that various mod- 
ifications may be made thereto, and it is intended that 
the appended claims cover all such modifications as fall 
within the true spirit and scope of the invention. 



Claims 

1 . A Web application development method for devel- 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 
as a servtet, JSP, and JavaBeans component 
(Bean), wherein 

in accordance with a GUI specification provid- 
ed by a design specification for said Web applica- 
tion system, a source filename of each component 
of the servtet, JSP, and Bean is defined correspond- 
ing to each screen image to develop the servlet, 
JSP, and Bean. 

2. A Web application development method for devel- 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 
as a servlet, JSP, and JavaBeans component 
(Bean), wherein 

in accordance with a GUI specification provid- 
ed by a design specification for said Web applica- 
tion system, a source filename of each component 
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of th servtet; JSP, ancrtfeanis defined in a onePto* 

one relationship corresponding to each screen im- 
age to develop the servtet, JSP, and Bean. 

A method for developing a Web application accord- 5 
ing to claim 1 or 2, wherein 

a source code of each component is automat- 
ically generated using the relationship between said 
screen and a source filename of each component 
of said servtet, JSP, and Bean, and information of '0 
said design specification. 

A method for developing a Web application accord- 
ing to claim 1 or 2, wherein 

said Bean component is provided with all 1$ 
pieces of information necessary for displaying an 
HTML page, and serves to carry out mapping infor- 
mation of an HTML page and information to be re- 
trieved from a database. 

20 

A method for developing a Web application accord- 
ing to claim 3, wherein 

upon generation of the source code of each 
component of said servlet, JSP, and Bean, 
a template list is displayed for each component to 2S 
be generated, a template selected from the tem- 
plate list is employed as a model, and a code is writ- 
ten to the model in accordance with said design 
specification to automatically generate a source 
code. 30 

A Web application development method for devel- 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 
as a servtet, JSP, and Java Beans component 35 
(Bean), comprising the steps of: 

reading a GUI specification provided by a de- 
sign specification to generate each component 
name of a servlet, JSP, and/or Bean corre- 40 
sponding to a screen name for each screen, 
selecting a template from a template list with 
respect to each component of a generated 
name, the template being a model of a source 
file of the component, and 45 
generating automatically a source code of the 
component by writing the code to said template 
in accordance with a design specification of the 
component. 

50 

A method for developing a Web application accord- 
ing to claim 6, wherein 

said template list includes a superclass tem- 
plate, and the step of generating automatically said 
source code is to inherit said superclass to create 55 
said source code. 

A method for developing a Web application accord- 



ing to claim 6, wh r in ~" 

said step of generating a name of each com- 
ponent is to generate a name of ach component 
of a servlet, JSP, and/or Bean in a one-to-on rela- 
tionship with a screen name for said ach screen. 

9. A method for developing a Web application accord- 
ing to any one of claims 1 to 8, wherein 

in a Web application system to be developed, 
the servlet serves to receive a request from a Web 
browser, the Bean serves to perform processing in 
accordance with the request of the servlet to hold 
resulting data; and the JSP serves to retrieve the 
resulting data of the Bean to generate an HTML dis- 
played on the Web browser; thus each role of the 
servlet, JSP, and Bean being separated from each 
other. 

10. A program provided by a method for developing a 
Web appl ication according to any one of claims 1 to 
9. 

11. A storage medium for storing a program provided 
by a method for developing a Web application ac- 
cording to any one of claims 1 to 9. 

12. A Web application development system for devel- 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 
as a servlet, JSP, and JavaBeans component 
(Bean), 

said system comprising means for developing 
the servlet, JSP, and Bean by defining a source 
filename of each component of the servlet, JSP, and 
Bean corresponding to each screen image, in ac- 
cordance with a GUI specification provided by a de- 
sign specification for said Web application system. 

13. A Web application development system for devel- 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 
as a servlet, JSP, and JavaBeans component 
(Bean), 

said system comprising means for developing 
the servlet, JSP, and Bean by defining a source 
filename of each component of the servlet, JSP, and 
Bean in a one-to-one relationship corresponding to 
each screen image, in accordance with a GUI spec- 
ification provided by a design specification for said 
Web application system. 

1 4. A system for developing a Web application accord- 
ing to claim 12 or 13, further comprising 

means for automatically generating a source 
code of each component, using the relationship be- 
tween said screen and a source filename of each 
component of said servlet, JSP, and Bean, and in- 
formation of said design specification. 
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32 



15. A system for developing^ Web application accord- 
ing to claim 12 or 13, wherein 

said Bean component is provided with all 
pieces of information necessary for displaying an 
HTML page, and serves to carry out mapping infor- 
mation of an HTML page and information to be re- 
trieved from a database. 



accordance with the- request ofihe servlet to hold 

resulting data; and the JSP serves to retrieve the 
resulting data of the Bean to generate an HTML dis- 
played on the Web browser; thus each role of the 

5 servlet, JSP, and Bean being separated from each 
other. 



16. A system for developing a Web application accord- 
ing to claim 1 4, further comprising 10 

upon generation of the source code of each 
component of said servlet, JSP, and Bean, 
means for displaying a template list for each com- 
ponent to be generated, for employing a template 
selected from the template list as a model, and for *5 
writing a code to the model in accordance with said 
design specification to automatically generate a 
source code. 

17. A Web application development system for devet- 20 
oping, on the Inter- and Intranet, a Web application 
system having server-side Java technologies such 

as a servlet, JSP, and JavaBeans component 
(Bean), comprising 

25 

means for reading a GUI specification provided 
by a design specification to generate each com- 
ponent name of a servlet, JSP, and/or Bean cor- 
responding to a screen name for each screen, 
means for selecting a template from a template 30 
list with respect to each component of a gener- 
ated name, the template being a model of a 
source file of the component, and 
means for generating automatically a source 
code of the component by writing the code to 35 
said template in accordance with a design 
specification of the component. 



18. A system for developing a Web application accord- 
ing to claim 1 7, wherein 40 

said template list includes a superclass tem- 
plate, and the means for generating automatically 
said source code are to inherit said superclass to 
create said source code. 

45 

1 9. A system for developing a Web application accord- 
ing to claim 17, wherein 

said means for generating a name of each 
component is to generate a name of each compo- 
nent of a servlet, JSP, and/or Bean in a one-to-one so 
relationship with a screen name for said each 
screen. 



20. A system for developing a Web application accord- 
ing to any one of claims 12 to 1 9, wherein 

in a Web application system to be developed, 
the servlet serves to receive a request from a Web 
browser, the Bean serves to perform processing in 
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Fig.2 System Configuration 
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Fig.3 
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Fig.4 Flowchart for generating a component table 
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Fig.5 Flowchart for automatically generating a source code 
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Fig.7 Generation of servlet source code 
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Kg.8 Source code of servlet superclass 
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Fig.9 Flowchart for automatically generating a JSP page source code 
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Fig. 10 Generation of a JSP page source code 
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Fig. 1 1 Flowchart for automatically generating a Bean source code 
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Fig. 12 Generating Bean source code 
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Fig. 13 Relationship between screen information and Bean 
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Fig. 14 Overall configuration of a Web application system employing Servlet, 

JSP, and Bean 
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Fig. IS Relationship between recipient and response components 
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Fig. 16 Definition 1 of recipient and response components 
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Fig. 18 Component definition table 
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Fig. 19 Component definition table 
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Fig.20 System configuration 



2002 



Central processing unit 



2008 



Component definition 
generating/editing unit 



200 9 



Code generating unit 



Code editing unit 




2003 



External storage unit 



2 0 04 



Design document 



2005 




Midi. I 



went definition data 



Template data 




Source code data 



36 



EP1 139 216 A2 



2 10 1 




Fig.21 Development procedure 
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Fig.22 Flowchart for generating component definition tabl 
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Fig.23 Flowchart for automatically generating a source code 
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Fjg_24 Flowchart for automatically generating a servlet source code 
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the session. 



Read the error specification to output the 
contents of the processing upon 
occurrence of an error. 



Generate the JSP name from the servlet 
as a JSP name to be used. 



Store the source file of the generated 
servlet in the source code data. 



End 



2409 



24 10 



24 11 



24 12 



24 13 



24 14 



rsr 
r. 
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Fig.25 Example f generating a servlet source code 



2 10 1 




2 50 1 



2 104 



n F A a 

//Package sentence C" 
package [Package name of tneservlet] ; 
// Import sentence 
import [Bean package name] .+; 



//Class definition 



2503 



public class [Servlet name] extends HttpServlet 

' /; 2 5 0 4 

public void service ( ^^"2 5 0 5 
HttpScrvletReqnest req, HttpServletResponse icsp ) 
throws ServletException, IOException 



{ 



2506 



// Generation of Bean 
bean » Beans instantiate ( getClassLoaderO, [Bean name] 



// Parameter retrieval and setting to Bean 
getParameter ( [Item name] 

^- 2507 

// Retrieval from session <r 2 5 0 8 
session.getAttribute ( Dtemtfame] ); 



// Execution of Bearu 2 5 0 9 
bean.doTask(); ^ 

// Storage in the session 
setSessionAttribute ( [Item name] ^parameter] ); 




); 



2 5 11 



// Processing upon error 

<« 



2 5 10 



_ 2 5 1 2 
// Calling JSP J> 

getRequestDispatcber ( [JSP name] ) Jorward ( req, resp ); ^ 



) 



Package specification 



Component definition table 



2 10 5 



190 1 



Screen transition diagram 



2 10 6 



Form data specification 



2 107 




2 10 8 



Error specification 



41 



EP1 139 216 A2 



Rg.26 Generation of a servlet source code 



Scrvlet template 



2)01 



2 60 1 



//Package sentence ^2 5 0 2 

package [Package name of the servlet] ; 
// Import sentence ^2 5 03 

import [Bean package name] ; — 

//Class definition ^ 2504 - 2602 



public class [Servlet name] extends [Superclass name] 

//Setting of initialization 2 6 0 3 
public void init 0 throws ServletException { 

^-2 6 0 6 
setBeanName ( [Bean name] ); — ^ 

^2607 
seJspPage ( [JSP name) ); ^ 

) 

. ^-2 6 04 

//Pre-processing ^> 

public void beforeTask 0 throws ServletException { 

// Retrieval from session 5 0 8 

session.getAttribute ( [Item name) ); --* > 

* 
* 

} 

— 2 6 0 5 

//Post-processing ^> 
public void afterTask 0 throws ServletException ( 

// Storage to session ^.2510 
session.setAttribute ( [Item name] , [Parameter] ); 

i 
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Fig.27 Servlet superclass code 

^- 2 7 0 1 ^-2 702 



public abstract class BaseServlet extends javax^ervletbttpJJttpServlet 

private String jspname; // JSP name ^ 2 7 0 3 

private String beanname; // Bean name 

private BaseBean bean; // Bean object 

<-2 7 04 

abstract public void init 0 throws ServletException ; 



public void service ( HttpServletRequest req, HttpServletRe spouse resp ) 
tiuows ServletException, IOException 2 7 0 5 

try | J> 

create 0; // Bean generation 

beforeTask 0; // Pre-processing 

dolask 0; // Bean execution 

afterTask 0; // Post-processing 

caUJspO; //JSP call 

) catch (Exception e ) J 

error 0; // Error processing 

j I ^2706 

private void create OtErows ServletException { 

// Processing for generating B^ 

protected void beforeTask 0 throws ServletException { 

// To be implemented in subclass if necessary 

j ^-2708 
private void doTask Othxows ServletException "\ 

II Processing for executing Bean 2 7 0 9 

protected void afterTask 0 throws ServletException | 

// To be implemented in subclass if necessary 

2 7 10 



) _ 

private void calUsp 0 throws ServletException^ 

// Processing for calling JSP 2 7 11 



private void error 0 throws ServletException | 

// Error processing 27 12 

) ~> 

void seJspPage ( String name ) ( this jspname » name; ) 
String getJspPage 0 I return jspname; J 
void setBeanName ( String name) { this .beanname « name; ) 
String getBeanName 0 1 return beanname; ) 
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Fig.28 Image of template selection 
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2 802 




Order system 
A-Top ^2803 

EJ— Menu 

SHNew order ^2804 

2805 



e|h Servlet 



Co nnrmServIe 



i 



I ConfirmBean 

B-JSP 



M HI 



iTCQ-JSp 



- •> , . Z-Z. - *«•,-■ 




• i . ■ -) . ^"1 - . - 



■QrCBBCEmiocnpH no oip|nencxi mj hu 

for comrminicaring with Java applet 

et provided by servlet API 
Servlet for outputting data in CSV form 



BascServ'et 



ChccklbScrvlct 

ConnApptetServIet 

HttpServlet 

CSVOutScrvlet 



i 



"Template name**: Basic servlet for controlling^can and ik$ ^ ^ 



"Class name** BascSovkt 

"Description*: Baseserrlet controb Bean and JSP. It receives a request from a diet* J 



and delegates its processing to the Beam. When the processing has been completed, k 
issues a request to the JSP for display. Hie JSP generates the screen dynamically with 
reference to the information in the Bean. 

"Source code** 



1 



2 8 11 
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Fig.29 Image of template selection 




29 0 1 2 9 0 2 



i 



He-in :c:nr-l;iic -election 



Bean 



Input request Bean 



Modification request Bean 
ion Bean 



2903 




BeanBean 
UserBean 



EntrvBean 



ModifyBean 

1 i ^tR^ an 



"J * *, 



trr. 



2 904 



2 9 0 5 



2906 



..... *' 



Basic JSP of input form 



JSP for delaying item list on a table 
Bask JSP of the confirm screen 



TableJSP 
ConfinnJSP 



i: 

(=5 



SP with a script for checking input 



CheckJSP 



SP for displaying calendar 



CakndarJSP 
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Fig.30 Flowchart for automatically generating a Bean source code 



Generation of a Bean source 



\ 



Create a file with the Bean filename 
iployed as the filename and with an 
extension sign of ".Java". 



Read a Bean template list from 
the template data. 



Select the corresponding template 
from the template list. 



I 



Read the package specification to 
generate package statement 



Employ the Bean name as the class 
name to generate the class 
declaration. 



Search and then generate the Bean 
superclass name from the class 
specification. 



I 



Generate the processing for 
executing the Bean from the 
sequence diagram. 



i 



Search the screen transition 
diagram for the original screen. 



Read the form data specification 
of the original screen to retrieve 
and output a parameter. 



3 00 1 



3002 



3003 



3 004 



3005 



3006 



3007 



3008 



3 0 0 9 



Read check items to generate the 
check processing of the parameter. 



3 0 10 



Generate the declaration of the 
attribute from the class specification. 



I 



3011 



Define and generate the setting of 
the attribute and the retrieved 
method. 

i 



30 12 



Read the method specification and 
generate methods other than the^T 
attribute setting and retrieval 



30 13 



Store the generated Bean source 
file in the source code data. 



3 0 14 



End 
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Fig.31 Example of generating a Bean source code 




3 10 2 



// Package sentence 
package [Package name of the 



_ 3 1 0 3 

// Class definitio] 

public class [Bean name} extends [Parent class of B< 

// Bean processing^ 3 10 4 
public void doTask 0 throws BeanException 
I 

if (check false) | 
throw new BaseServlet 0; 

' ^ 3 10 5 

// PnXCSSLQg ^ 



i] 




// Check for parameter <f 

protected boolean checkO 
I 



3 10 6 



// Parameter retrieval 

getParameter ( [Item name] ); 

: 3 108 

II Parameter check ~> 



3 10 7 



return true; 



3 10 9 



// Attribute declaration 



3 110 



// Retrieval of attribute and 



definition of setting method 



// Definition of other methods <- 
) "^3 l l l 



2 104 



Package specification 



Component definition 
table 



Screen 

transition diagram 



Form 

data specification 



Checklist 



19 0 1 



2 113 



2 115 



2 10 5 



2 10 6 



2 112 




2 114 
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Fig 32 Relationship between screen information and Bean 
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3 202 
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New order confirmation 



User name guest , r 

Date:»0Q/1/3O^ 

Date of delivery: March 16, 2000 < »»■ 

An estimate with the following configuration 



<M»ron500Mtt < AGOtL^. 

MMfcfcmory ItOOO 
IDE OG eft* 1O300 

15-inch CRT display 20000 
|Number of sets one^^ 59000 



CPU 
Memory 
3 Hard Disk 
!? Monitor 



M 



* 



r 
■ 




Executing "Order confirm" places an order for PC configured *s sdccicd 




ConfinnBean 




User name 
Date 

Date of delivery 
Each name [4} 
Each unit price [4] 

Sum 

Number of sets 
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Fig.33 Flowchart for automatically generating a JSP source code 



Generation of a JSP source code. 

i - 



j 



Create a file with the JSP filename 
employed as the filename. 



3 3 0 1 



Read the HTML file of the screen 
image. 



i 



3 302 



Generate the contents of the 
HTML file. 



3303 



Read a JSP template list from the 
template data. 



3 3 04 



Select the corresponding template 
from the template list 



330 5 



Generate the Bean name as a 
class to be used in JSP. 



i 



3 3 06 



Read the event specification to 
generate a script definition. 



3 3 0 7 



Search the screen transition 
diagram for the linked screen. 



3 3 08 



Search the component table for 
and generate the servlet name of 
the linked screen. 



3 30 9 



Read the form data specification to 
generate the name of form parts. 



I 



3 3 10 



Read the class specification to output 
the attribute name of the Bean where 
appropriate. 



I 



3 3 11 



Read the method specification to 
output the method of die Bean where 
appropriate. 



3 3 12 



Store the generated JSP source 
file in the source code data. 



I 



3 3 13 



End 



i * 



fx: 
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Fig.34 Example of generating a JSP source code 



2 12 6 



2 119 

s 



Screen image 




<%© page contentType^ext/htmT %> 

<jsp.-uscBean id= w obj w type~ [Bean name] 

</j$p:uscBcao> "> 

^3402 

<HTML> 
<HEAD> 

<SCRIPT> 3 4 0 3 

<!- J> 

II Script definition 



//-> 

</SCRIPT> 

</HEAD> 

<BODY> 



3404 



<FORM action" [Destination servlet name] > + 



< INPUT namc=» [Item name]^~ 



340 1 




34 0 5 ^-34 06 

<jsp:gctPropcrty name^obj" property^ [Attribute name) /> 

<%=>d. [Method] t> 

</FORM> 




<7BODY> 
</HTML> 



190 1 



Component definition 
table 



Screen transition diagram 
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Fig.35 Image of editing source codes 
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B-JSP 

I— confirm. jsp 

fp- Order completed 
Existing order list 

( 3 — Exbi 'm g onto catt crt s coafirai 

E J- Order change 
ffl— Order cancel 




mmmmm. 
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